Why this? Why didn't you answer to my comment in the issue? I don't want data model changes if they are not justified.

I'm trying to adopt the new datamodel. I'm not saying it's the best choice, but I want to try and see what difficulties I face.
I now have the full stack working: account_payment_base_oca + account_payment_order + account_banking_pain_base + account_banking_sepa_credit_transfer + account_banking_mandate + account_banking_sepa_direct_debit. So I am able to make full scenarios and see the real problems I face and try to address them.
At the moment, it's too early to list them, because I'm currently performing the tests.

Then we are going to have 2 forks. I don't want that "datamodel", as it's very bad as explained in the migration issue.

I just pushed a new version of account_payment_base_oca. In this new version, the active field of account.payment.method.line (added by account_payment_base_oca) is set to False by default. So, when a account.payment.method is added, all the account.payment.method.line automatically created by Odoo are inactive. You can active the ones you need and leave the others inactive.
You still have the option bank_account_link = "variable" as in Odoo v17-. When "variable" is selected, a M2M field alternative_journal_ids is displayed ; the possible journals are journal_id + alternative_journal_ids. journal_id acts as the default journal.
When you confirm a payment order that has a payment_method_line_id configured as "variable", Odoo will search the account.payment.method.line with the journal selected on the payment order and the same payment method and use that on the account.payment.
My first tests are positive.
I'll push the code of the other modules in a few days.

I sincerely see it as a nonsense to have to look for "similar" things one way and the reverse because of a failed datamodel putting the data at journal level. You can't for example group by this field if you select different lines according the journal but representing the same payment mode. Let's keep our account.payment.mode model, and we can link the account.payment.method.line on the generated payment as we were doing previously.

@pedrobaeza It's also a big temptation for me to keep account.payment.mode. In fact, I'm the one who introduced account.payment.mode in v9 during the Sorrento code sprint (to replace payment.mode that was dropped by Odoo SA with the removal of the module account_payment from the official addons), so it's kind of my baby and I like it.

But, in the long list of wired/sub-optimal datamodel of Odoo SA that I would love to avoid/change, this one is not a big deal. I think I found a solution that is acceptable and the balance between the advantage of being compatible with the native datamodel and the drawbacks of using the trick I propose to make the new datamodel work with bank_account_link = 'variable' tend towards the adoption of the new datamodel I think. I'll continue my tests in the coming days to make sure I don't discover any other problems and I'll publish the upper-level modules.

This sounds promising. I also prefer using the native account.payment.method.line if that is possible.

I insist: how it would be better to assign at partner level the payment method line linked to a specific journal, seeing all of them in the dropdown (and this active=False trick is something conflicting with the way Odoo expects to work), instead of having an agnostic payment mode?

The payment method lines are not new. They are there since ages (v14). The only new thing is that there's a many2one at partner level, but that doesn't change anything. Please don't go with this, or we will have 2 account_payment_order modules.

Another reason spotted now for not switching from account.payment.mode: the missing logic about the mode on refunding invoices.

@pedrobaeza I think Alexis is doing a lot of very valuable work here. Let's wait a bit to see where this goes.

No, if the foundations are incorrect, no more work should be put in here. I announce my intention on continuing with the old stack if you switch, and the model names should be preserved for the existing things according current establishment.

Sorry I don't understand your arguments, Pedro. Odoo is evolving and it seems normal to me to explore and see if we can adapt.

The arguments are clear of the cons of switching, so I'm just stating that I would push for the previous approach and this will conflict in the model names, and it's clear that these cons can't be bypassed without doing ugly hacks and standard code overrides.

Note that I'm the first one embracing upstream changes when they are suitable for the goal of the modules. I did the refactoring to account.payment in v14, and thanks to that, we have enjoyed 5 versions without having to touch continuously the journal entry generation, delegating that to core mechanisms.

But in this case, it has no benefit to go with a simple wrong m2o extra field that they have added in the partner, and that is so wrong in the concept. And I insist that the account.payment.method.line is not something new. It's there since ages, and we set it correctly on the generated account.payment. The only change is about the partner preferred payment mode.

Hello all, I try to understand this part :) Is there a document that list user case for payment_mode use. This can be a good way to check If new or old datamodel can be used and if there is a problem with ?

I think à create a document but if you have one, I will try not to start with empty blank sheet :)

Basically, the payment mode tries to model the payment "instrument" that the customer (or you for vendors) is going to use. Let's say "Wire transfer", "Check", "SEPA Direct Debit", etc.

The new Odoo field in standard is just adding a sublevel, like SEPA DD for journal (bank) X, so the side effects are:

• You will see N "Sepa Direct Debit", as many as journals you have declared for using that payment method, being very confusing for the user.
• You may want to change to other bank for doing the operation in any moment.

That's way the other data model avoids this problem doing an aggregation before, and only "unfolding" to the corresponding bank (journal) on the final end when you do the payment/debit order (although you can constraint to one or several banks from the beginning if you want).

This PR tries to "bypass" the side effects doing that you select one of the many "SEPA Direct Debit", and it's changed "on the fly" when doing the payment order.

But keeping this so long stable (and simple) extra data model avoids all these problems, and we have also provided other useful tools around it like dynamic text shown in the invoice (for saying in which customer bank account is going to be done the DD, own bank account for wire transfer, etc), that will be lost (or redone) in case of the switch. We can hide totally this other m2o field in the partner view for not having any confusion, at that's all.

For me is a total nonsense to even consider doing this switch.

We need to unblock this for having a complete 18.0, and unless other strong opinions against arise, the natural trend is to keep what we have in previous versions and discuss later any refactoring (if any). We will resume the migration work next week doing the raw migration fine-tuning the UX.